home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000069_icon-group-sender _Fri Feb 27 08:17:05 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  8KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id IAA11456
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Fri, 27 Feb 1998 08:17:05 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA32434; Fri, 27 Feb 1998 08:17:04 -0700
  7. From: gep2@computek.net
  8. Date: Fri, 27 Feb 1998 01:10:16 -0600
  9. Message-Id: <199802270710.BAA08211@axp.cmpu.net>
  10. Mime-Version: 1.0
  11. Content-Type: text/plain
  12. Content-Transfer-Encoding: 7bit
  13. Subject: Re: Translation into C
  14. To: icon-group@optima.CS.Arizona.EDU
  15. X-Mailer: SPRY Mail Version: 04.00.06.17
  16. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  17. Status: RO
  18. Content-Length: 7532
  19.  
  20. >>> Mark Evans suggested that the reason one might want an Icon to C
  21. > translator is that the resulting program will execute faster because it
  22. > doesn't need to be interpreted.  But I wonder how much difference that
  23. > would really make.  If the C program spends most of its time calling
  24. > library routines, then I wouldn't expect much difference at all.
  25.  
  26. >> Right.
  27.  
  28. > I don't follow the logic here.  Even compiled C programs spend most of
  29. their time inside libraries (system, numerical, string, file).  
  30.  
  31. Yes, but C programs tend to spend a lot of time in directly executed mainline 
  32. code... address computation, integer arithmetic, pointer dereferencing, much 
  33. character handling, most testing and branching, case statements, if/then, most 
  34. tests and conditionals, etc. etc.  It's relatively rare for C programs that 
  35. don't EXPLICITLY call functions to use runtime library calls.  Compare this 
  36. against a much higher-level language like Icon or S*BOL, where virtually every 
  37. statement probably involves NUMEROUS runtime library routine calls.
  38.  
  39. > I have some anecdotal statistics of my own.  I have used several
  40. interpreted languages related to numerical analysis; let's take four of
  41. them, Mathematica, MATLAB, O-Matrix, and LabVIEW.  In principle, all of
  42. them are interpreted except LabVIEW, which claims to be "compiled."
  43.  
  44. > I've used Mathematica more than any of them and it is closest in nature
  45. to Icon.  It is very high-level.  The usual case is that I prototype an
  46. algorithm in MMA and then port it to C.  The resulting speedup is
  47. usually larger than 10x, sometimes 20x to 50x.  The example I am
  48. thinking of is 2D image convolution.  I know how to code well in MMA so
  49. I know it's not my skill involved here.  MMA has dynamic typing and
  50. other goodies similar to Icon.  In fact the two are fairly close in many
  51. respects.  It's very easy to create data structures in either language.
  52.  
  53. I think you're comparing apples and oranges.  I suspect that if you tried to do 
  54. everything that MMA does (including dynamic typing etc) in your C port, it would 
  55. perform a lot closer to the Mathematica one.  You're comparing a highly general, 
  56. higher-level tool against a much more tailored, more machine-specific C 
  57. implementation... I'd *expect* the C one to be a lot faster.
  58.  
  59. I don't think it's as much due to the "compiled/interpreted" issue as you seem 
  60. to think it is.
  61.  
  62. > MATLAB - One of my clients recently asked a local robotics research
  63. outfit (ARRI) to build a simulation of their hydraulic system.  They
  64. used MATLAB and then switched to C for speed.  They switched on their
  65. own initiative because MATLAB was too slow.  The speedup was on the
  66. order of 40x (forty minutes down to one).  This was for a time-domain
  67. simulation of a relatively simple hydraulic strut invovling pressure,
  68. temperature, and bulk modulus changes to figure out the spring and
  69. damping forces.  Several nonlinear dynamical equations involved.
  70.  
  71. Same point as above.
  72.  
  73. > O-Matrix - an unusual case (http://www.omatrix.com).  This is
  74. essentially a MATLAB clone.  What make it interesting is that the
  75. company claims a 5x speed improvement over MATLAB, not by eliminating
  76. interpretation, but BY WRITING THE LIBRARY ROUTINES EFFICIENTLY.  I
  77. inquired specifically about this some while ago and the answer came back
  78. that it was basically their hand-tuned assembly-language libraries that
  79. gave them the edge over MATLAB's plain Jane C libraries.  So yes,
  80. library implementation can make a huge difference.
  81.  
  82. Obviously.  Did YOUR tests confirm the 5x improvement?
  83.  
  84. > LabVIEW - Very interesting indeed.  The vendor uses a kind of
  85. compilation in LabVIEW of a nature that they say is "as fast as C."   It
  86. may be so for some simple Whetstone types of benchmarks, but in general
  87. I have done algorithms both ways, and LabVIEW's speed doesn't hold a
  88. candle to C.  I would estimate the slowdown again at 10x-20x or
  89. thereabouts.  I have used LabVIEW extensively and know how to code it
  90. well.
  91.  
  92. Same point as (way) above.
  93.  
  94. When I first started programming, my first language was PL/1, and I got to be 
  95. pretty good at it.  Among other things, I studied the generated pseudo-assembler 
  96. code listings, and it really wasn't that bad (and in fact, under the Optimizing 
  97. Compiler, it got to be really quite good).  The problem was in the runtime 
  98. libraries, which obviously had been programmed by programmers who were a *great* 
  99. deal less skilled (and/or motivated) to do a good job than the people were who 
  100. implemented the compiler itself.  As long as you could keep the compiled code 
  101. out of the libraries, it _flew_.  Code which included a lot of library routine 
  102. calls was virtually guaranteed to be slow.
  103.  
  104. I'm not suggesting that Icon's libraries and runtime are badly written... but 
  105. merely that a language like Icon which spends the great majority of its time in 
  106. runtime library ANYHOW simply probably won't gain nearly so much performance 
  107. improvement as a result of having the mainline compiled instead of 
  108. interpreted... and in fact, I think I remember reading in the Icon Newsletter 
  109. (years ago now) that one of the reasons they dropped support for the Compiler 
  110. (once upon a time) was because it was a maintenance hassle, and benchmarks 
  111. showed that the performance improvement for typical Icon programs was pretty 
  112. small in any case.
  113.  
  114. > All of the above indicate to me that no interpreted system in existence
  115. has yet come close to C even though they claim to have done so.
  116.  
  117. That shouldn't really surprise anybody, since C is a hugely low-level language 
  118. (almost assembler language) with structures which largely map one-to-one with 
  119. machine instructions.  C is also typically used for fairly compute-intensive 
  120. stuff that is programmed at a very low level, where the mainline execution speed 
  121. is very important.  C also has little or no protection against things that most 
  122. higher level languages often try to protect you (and themselves, for that 
  123. matter) against... memory mismanagement, out-of-bounds array and string 
  124. accesses, etc etc ad infinitum.  Higher level languages also often try to do a 
  125. lot more error control and reporting than C tends to do.  All of that extra 
  126. stuff *does* take overhead, and usually the programmers of the higher level 
  127. languages simply accept this as part of the cost of their more powerful system.
  128.  
  129. Of course, there is some rationale for this argument, when even quite 
  130. substantial computers (166MHz Pentium class performance, complete with 
  131. multimedia, modem, and everying) sell *retail* for less than $500.
  132.  
  133. And for those people who TRULY have to struggle to optimize their programming to 
  134. the N-th degree, there are ultra-fast specialized processors (like the marvelous 
  135. TI DSP, a quite neat little CPU selling for less than $100 in production 
  136. quantities and which executes up to 1.6 - 2.0 billion instructions per second). 
  137.  A coprocessor board based on this little gem (or maybe several of them), 
  138. plugging in to a PC, could outperform even fairly recent supercomputers on 
  139. really heavily compute-intensive tasks.
  140.  
  141. I think the reason why we've not seen more such things on the market is because 
  142. it's relatively rare that very many people TRULY NEED this level of performance.
  143.  
  144. Anyhow, processing power and disk space HAVE gotten cheap enough that it can be 
  145. wasted by the fistful, (regardless of how that dismays many of us);  programmer 
  146. time is very often a far more critical issue than runtime performance.
  147.  
  148. Gordon Peterson
  149. http://www.computek.net/public/gep2/
  150. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  151.  
  152.